This application is related to the following commonly assigned, co-pending patent applications: Ser. No. 08/719,163, entitled INTERACTIVE INFORMATION TRANSACTION PROCESSING SYSTEM WITH UNIVERSAL TELEPHONY GATEWAY CAPABILITIES, by Michael Polcyn, filed Sep. 24, 1996; Ser. No. 08/846,961, entitled SWITCHLESS CALL PROCESSING, by Ellis Cave, filed Apr. 29, 1997; and Ser. No. 09/163,234, entitled INTERACTIVE INFORMATION TRANSACTION PROCESSING SYSTEM ON IP TELEPHONY PLATFORM, by Michael Polcyn, filed Sep. 29, 1998, which is a continuation of application Ser. No. 08/719,163; all of which applications are incorporated herein by reference.
This invention relates generally to a system and method for facilitating the transfer of information via an asynchronous packet network, and more particularly to a system and method for redirecting media in an asynchronous packet network.
Voice Response Units (xe2x80x9cVRUsxe2x80x9d) have existed in the prior art for many years, and are generally defined as robotic systems that automatically interact with one o r more persons for the exchange of information and the enhancement of communications. There are numerous enhanced services capable of being provided by a VRU, including voice messaging, automated collect calling, international callback, prepaid and postpaid calling card, store and forward, one number service, find me, follow me, 800/900 service, automated customer service, automated agents or attendants, voice activated dialing, prepaid and postpaid wireless, conferencing, and other such enhanced services.
In the prior art, synchronously switched VRUs were initially connected to the Plain Old Telephone system (xe2x80x9cPOTSxe2x80x9d) network (i.e., the Public Switched Telephone Network (xe2x80x9cPSTNxe2x80x9d)) via analog interfaces. Although POTS analog connections still exist, the use of digitized voice transmissions is becoming increasingly common on the PSTN. Because of the advantages of digitized transmission, a synchronous VRU is now typically connected to the POTS network via a digital interface, as disclosed in co-assigned U.S. Pat. No. 5,818,912, entitled FULLY DIGITAL CALL PROCESSING PLATFORM, by Daniel Hammond, issued Oct. 6, 1998, which application is incorporated herein by reference. An example of such a VRU is shown in FIG. 1, wherein synchronous VRU 100 is digitally connected to PSTN 102 via T1 trunk 104 using a standard Integrated Services Digital Network (xe2x80x9cISDNxe2x80x9d) format. Digitized voice signals transmitted over the PSTN normally consume approximately 64 Kilobits-per-second (xe2x80x9cKbpsxe2x80x9d) of bandwidth when digitized and encoded according to the G.711 compressed format using pulse code modulation (xe2x80x9cPCMxe2x80x9d) and the standard xcexc-law or A-law logarithmic algorithms.
Generally, in the prior art, the PSTN was originally designed to be managed and controlled by a single entity, and later developed such that very few entities control the primary switches that make up the network infrastructure. Generally, because control of the network is centered inside the PSTN switches and because the PSTN switches are of a proprietary nature, very little control over the switching mechanisms is available to other entities that do not own the switches in the network. For example, each specific connection made by VRU 100, e.g., to telephone 106a, generally requires its own port and a 64 Kbps channel. If the enhanced service being provided by VRU 100 requires connecting telephone 106a to another device external to VRU 100, for example to telephone 106c, there are limited options available to VRU 100, each with its own tradeoffs as explained below.
First, PSTN 102 may transfer a call via Release Link Trunking (xe2x80x9cRLTxe2x80x9d) by sending control signals to a switch in the network. For example, a calling party using telephone 106a may wish to call another party at telephone 106c using an 800 calling card service provided by VRU 100. After the calling party enters a Card Number, personal identification number (xe2x80x9cPINxe2x80x9d) and the phone number for telephone 106c, VRU 100 verifies the information and then connects the two parties using RLT via PSTN 102. In using RLT, VRU 100 gives up control of the call to PSTN 102, although VRU 100 may send the customer""s card number and PIN to PSTN 102 for tracking purposes. Generally, a useful and desirable 800 calling card service feature known as call re-origination allows the calling party to disconnect from the called party and reconnect to another called party without breaking the calling party""s initial connection. Typically, the calling party on telephone 106a may hold down the # key for more than two seconds to signal to the network the calling party""s desire to make a new call, although many other signals and durations may be used. Because VRU 100 has relinquished control of the call to PSTN 102, PSTN 102 must monitor the call for the # key dual-tone multi-frequency (xe2x80x9cDTMFxe2x80x9d) signal so that PSTN 102 may then reconnect the calling party on telephone 106a to VRU 100. PSTN 102 also sends the customer ID and PIN back to VRU 100 so that the customer does not have to reenter this information. This approach has the advantage of freeing up the VRU ports for other callers, but it requires PSTN 102 to have an application running for tracking the customer""s ID and PIN, and for monitoring the call for DTMF signals.
Second, a user such as VRU 100 may use a hook flash to request that PSTN 102 directly connect telephone 106a to telephone 106c. This also has the advantage of freeing up ports on VRU 100, but VRU 100 permanently loses the call context. Unlike RLT, the hook flash does not allow VRU 100 to retrieve the call context from PSTN 102. The VRU then cannot perform important call control or administrative functions such as monitoring, recording, timing, or charging for the phone call. Because the call context is lost for VRU 100, the calling party generally must reenter the Card Number and PIN, in addition to the new destination phone number, and VRU 100 must re-verify the calling party""s information. Reentering these numbers can be frustrating to customers, and consumes extra connection time and processing resources.
Alternatively, the connection between the two parties may be bridged between the telephones within VRU 100. Internal synchronous switch 112 and another port and 64 Kbps channel are required to complete the connection to telephone 106c. VRU 100 does not relinquish control of the call to PSTN 102, so VRU 100 may still perform call control and administrative functions. In addition, VRU 100 may monitor the call for DTMF signals. If in the calling party using an 800 calling card service wishes to make another call, the calling party may hold the # key for more than two seconds. VRU 100 detects this signal directly, and can disconnect the called party on one port from the calling party on the other port. Because VRU 100 maintained the call context, the calling party""s Card Number and PIN do not have to be reentered and re-verified. The calling party may simply enter the new destination phone number, and VRU 100 may then set up a new connection using another port. However, this alternative requires VRU 100 to implement internal switch 112, and uses two circuits in the network and two ports on VRU 100, one for each party. Thus the VRU ports generally stay engaged for the entire duration of the phone call, instead of being made available for use on other phone calls. This is undesirable because unlike a simple switch, VRU ports are generally expensive resources that provide enhanced functions, such as voice recognition, DTMF detection/generation or text-to-speech conversion, for interacting with callers. Normally, the network owners would like to always keep the VRU port busy handling new calls. However, since the VRU ports ate used to access the internal switch, the VRU ports are engaged during the entire call, even though the port is idle.
In addition to internal switch 112 and extra network bandwidth used, a VRU bridged connection may also travel over an inordinate amount of distance. For example, a calling party in Houston, Tex., may wish to call another party in New Orleans, La., using an 800 calling card service provided by a VRU. If the VRU is located in either of those cities, then the bridged call does not travel much extra distance compared to the physical distance between the actual parties. If the VRU is located in Los Angeles, Calif., however, the inbound call to the VRU must travel all the way to Los Angeles from Houston, and the outbound call from the VRU must travel all the way to New Orleans from Los Angeles, which is an inefficient use of network resources.
Other problems with synchronously switched networks exist. They generally are expensive to build, difficult to upgrade once built, and not flexible enough to support new multimedia services. In response to these difficulties, along with other factors, there has been a dramatic increase in recent years of the availability of public packet networks, such as the Internet, other wide area networks (xe2x80x9cWANsxe2x80x9d), and local area networks (xe2x80x9cLANsxe2x80x9d), to exchange information, for example, in voice format. PSTN circuits generally multiplex digitized voice signals by allocating sequential bits or words in separate conversations to periodic time slots in a time division multiple access (xe2x80x9cTDMAxe2x80x9d) structure. The PSTN requires a switched architecture and point-to-point connections, and the data is transmitted continuously, so PSTN connections use up bandwidth needlessly when voices are silent during a call. On the other hand, packet networks asynchronously send digitized signals in packetized form, where each packet is encoded with a header that references its destination and sequence. The packets are only sent when there is information to send, thus packet networks do not need to send packets when the callers"" voices are silent, saving bandwidth.
In a packet network, the packets may follow one of many possible pathways to their destinations before they are reassembled, according to their headers, into a conversation. Generally, this has the disadvantage over the POTS/TDMA method in that the packet headers consume additional bandwidth. The packet header disadvantage is generally believed to be outweighed by the efficiencies in network usage without switched architecture and point-to-point connections because, for example, a synchronous network continuously uses the same bandwidth even if there is no substantive signal to transmit.
In part to promote interoperability in the fast developing packet network technology area, the International Telecommunications Union (xe2x80x9cITUxe2x80x9d), located in Geneva, Switzerland and with a World Wide Web (xe2x80x9cWWWxe2x80x9d) site of xe2x80x9chttp://www.itu.org,xe2x80x9d has developed the H.323 standard for real-time multimedia (defined herein as including voice, video, data, or any combination thereof) communications and conferencing for packet-based networks. The H.323 standard, entitled xe2x80x9cPacket-based Multimedia Communications Systems,xe2x80x9d released February 1998, is incorporated herein by reference, and is actually an umbrella standard for a series of specifications that describe how multimedia communications occur between terminals, network equipment and services on packet networks (e.g., Internet Protocol (xe2x80x9cIPxe2x80x9d) networks), some of which do not provide a guaranteed Quality of Service (xe2x80x9cQoSxe2x80x9d). The standard is based on the Internet Engineering Task Force (xe2x80x9cIETFxe2x80x9d) real-time protocol (xe2x80x9cRTPxe2x80x9d) and real-time control protocol (xe2x80x9cRTCPxe2x80x9d), with additional protocols for call signaling and data and audiovisual communications. Another protocol, the resource reservation protocol (xe2x80x9cRSVPxe2x80x9d), may be implemented in routers to establish and maintain requested transmission paths and QoS levels. Generally, a protocol that guarantees a QoS level has mechanisms for ensuring the on-time delivery of traffic signals, recovering lost packets, and guaranteeing bandwidth availability for specific applications.
Some of the specifications referenced by the H.323 standard include call control and framing specifications, such as H.225, Q.931, and H.245, audio codec specifications, such as G.711 for high bit rate connections and G.723 for low-bit-rate connections, video codec specifications, such as H.261 for high bit rate connections and H.263 for low-bit-rate connections, and data communications specifications, such as T.120 standards. The H.323 standard defines several entities that may exist on a packet network: terminals, Multipoint Control Units (xe2x80x9cMCUsxe2x80x9d), gatekeepers, and gateways. Terminals support at least voice communications and optionally support multimedia communications, and include such components as personal computers and IP phones with at least voice capability and optionally multimedia capability. MCUs support conferencing for three or more network endpoints. Gatekeepers provide network management and virtual Private Branch Exchange (xe2x80x9cPBXxe2x80x9d)-type capabilities, such as call control services like address translation for network endpoints. Gateways support at least voice and optionally multimedia inter-networking for connecting IP packet-based networks with circuit-switched networks, and provide translations between different transmission formats, communications procedures, and codecs.
A synchronous VRU may interface with an asynchronous packet network via a PSTN/packet gateway. A PSTN/packet gateway converts TDMA voice signals received, for example, over a standard PSTN line, into packetized voice signals, and vice versa, and allows the resources in the PSTN network to exchange information with resources in the packet network. Generally, the PSTN/packet gateway also performs conversion of analog signals to digital signals (if required), or accepts the xcexc-law encoded digital signals directly from the PSTN. The gateway may optionally compress the digitized signals from xcexc-law (about 64 Kbps) down to as low as about 5 Kbps before packetizing (and vice versa). The packetized voice signals may be multiplexed with numerous other signals for transmission over a data line. A typical application of such a PSTN/packet gateway is providing an alternative to making a long distance call. Instead of making a long distance connection where the network uses digital TDMA lines at approximately 64 Kbps of bandwidth per call, callers may make a local POTS call to a PSTN/packet gateway. The gateway may digitize, if necessary, and optionally compress the incoming signal down to about 5 or 6 Kbps. The gateway then packetizes the signal. These packetized signals may then be multiplexed and routed in bulk very cheaply over long distances on a data grade network. At the other end, another PSTN/packet gateway receives and reassembles the packetized signal, and then decompresses the signal, if necessary, and converts it back into a TDMA-multiplexed signal. Resources at the distant gateway then make another local POTS call to complete the connection between the calling party and the receiving party.
A synchronous VRU connected to a PSTN/packet gateway may provide the enhanced services described above, and take advantage of the additional capabilities of the packet network. Such a system is one of the systems discussed in co-assigned, co-pending patent application Ser. No. 08/719,163, entitled INTERACTIVE INFORMATION TRANSACTION PROCESSING SYSTEM WITH UNIVERSAL TELEPHONY GATEWAY CAPABILITIES, by Michael Polcyn, filed Sep. 24, 1996. An example of such a system is shown in FIG. 2. As discussed in application Ser. No. 08/719,163, the VRU (i.e., Interactive Voice Response Unit (xe2x80x9cIVRxe2x80x9d)) may be an automated voice resource known in the art, such as the xe2x80x9cOneVoicexe2x80x9d or xe2x80x9cIN*Controlxe2x80x9d platforms, available from InterVoice, Inc., 17811 Waterview Parkway, Dallas, Tex., 75252. Ports on the VRU receive individual communications, and resources in the VRU perform processing to make communications in one format (e.g., asynchronous data in the packet network) understandable to communications in other formats (e.g. synchronous data in the POTS network).
In the example system shown in FIG. 2, synchronous VRU 200 connects to PSTN 202 via T1 trunk 204, as in FIG. 1. In addition, VRU 200 connects to PSTN/packet gateway 214 via T1 trunk 212, and gateway 214 is connected asynchronously to packet network 216. If telephone 218 is physically located in a different area than VRU 200, access to VRU 200 via the POTS network may require a long distance phone call. To reduce the cost of this connection, telephone 218 may access PSTN 220, which in turn provides a synchronous connection to gateway 224 via T1 trunk 222. Because data in PSTN 220 is in G.711 format, gateway 224 may translate the data into G.723 compressed format for transmission over asynchronous packet network 216, or gateway 224 may leave the data in G.711 format and not change the compression format for transmission over packet network 216. Gateway 224 also provides the appropriate headers for routing the packets to gateway 214. Gateway 214 may then decompress the reassembled packets, if necessary, from G.723 format and translate the data into G.711 format for transmission to VRU 200 over T1 trunk 212. As with the system in FIG. 1, each specific connection made by VRU 200 generally requires a port and a 64 Kbps channel on T1 trunk 212. If the enhanced service being provided by VRU 200 requires connecting telephone 218 to another device external to VRU 200, for example to telephone 206 or telephone 232, then internal synchronous switch 238 and another port and 64 Kbps channel are required to complete the connection. In addition, if the connection to the external device is back through gateway 214 and packet network 216, the entire sequence of compression/decompression, if necessary, and translation must be performed again.
While a synchronous VRU connected to a gateway may take advantage of many of the benefits of a packet network over a switched network (e.g., lower cost long distance), this type of implementation is probably best applicable as an interim solution. For example, there may be some drawbacks associated with the implementation described above. First, packet networks, not switched networks, appear to be the dominant type of network for future communications, and thus the synchronous interface in a VRU may become less utilized.
Second, even though a synchronous VRU may be connected to a packet network via a gateway, the VRU still generally requires an internal switch to connect one party to another for many enhanced services, such as calling card and one-number services. When the call media stream passes through the VRU, the application generally uses two ports to complete the connection, and the VRU ports stay engaged in the call for the duration of the call. Typically, prior art VRUs switch synchronous data in G.711 format, which is the same format as used by the switches in the PSTN. Because of this, if data arrives in asynchronous G.711 format, or G.723 format, the data must be converted to synchronous G.711 format so that the VRU can process it.
Third, the repeated conversions from one data format to another data format, such as from G.711 to G.723, or from synchronous to asynchronous, may delay or degrade the data, and also use up processor resources which could be used for other functions more directly related to the core functionality of the VRU.
Another difficulty with a synchronous VRU being connected to a packet network via a gateway is that this VRU is architecturally in the position of a gateway, which is a network xe2x80x9cedgexe2x80x9d device. These edge devices are generally expected to handle data translations and multiple device-type (e.g., voice, data modem and fax) access to the packet network. However, the digital signal processor (xe2x80x9cDSPxe2x80x9d) power required for voice over Internet protocol (xe2x80x9cVoIPxe2x80x9d) compression, V.90 data modems, or fax modems, for example, is relatively high. In a VRU, this processing power would be better utilized performing enhanced services, such as voice recognition and DTMF detection, which are more directly related to the core functionality of the VRU. Alternatively, the data translation would be better placed in a device which is intended to be a network edge device, such as a gateway, allowing the VRU to function with less processing power, and thus be more cost efficient.
There are many enhanced services provided over the PSTN network that are just as applicable to and useful in a packet-based network. Generally, customers will still want the types of enhanced services provided by VRUs even if they are using a packet network instead of the POTS network, and even if the media contains voice, video, data, or a combination thereof, instead of voice only.
These and other objects, features and technical advantages are generally achieved by a system and method for a packet VRU which directly utilizes packet network protocols, such as those of the H.323 standard, to provide enhanced services in a packet network. The VRU may directly connect to the packet network as a network xe2x80x9ccorexe2x80x9d device, or connect via another network core device, such as an H.323 gatekeeper. In contrast to a network edge device (e.g., a gateway), a network core device (e.g., a gatekeeper or a router) generally operates xe2x80x9cwithinxe2x80x9d the packet network and is not required to provide data format translation (e.g., synchronous to asynchronous) or multiple device-type access (e.g., fax and modem). Advantageously, the packet VRU may be built entirely in software running on a network server with a standard packet network connection such as Ethernet or token-ring. The H.323 software protocol may contain all of the call placement, progress, and termination functions, implemented as out-of-band signaling in a format similar to ISDN""s Q.931 standard.
In a preferred embodiment of the present invention, a packet VRU may connect two or more parties together via the packet network, such as for an 800 calling card service or for a teleconferencing service. Analogous to the discussion above with respect to the synchronous VRU connected to the PSTN, it is desirable for the packet VRU to be able to connect two or more parties together and still maintain control of the call. This includes call administrative functions, tracking call context, processing input from users, etc. Therefore it is generally useful for a packet VRU to maintain control of the call and receive user input, signaling, or the audio stream, for example to detect user input indication (e.g., DTMF) messages, interpret voice input, or sum voices in a conference call. One way to accomplish this is for the packet VRU to receive and process the packets sent by a source, and then re-transmit the packet information to the proper destinations.
However, there are generally three important sources of delay encountered when transmitting data across a packet network. First, there is a delay introduced if the data is compressed by the source. Generally, the source gateway must receive and store enough data in order for it to execute the compression algorithm. Depending on the specific algorithm used, compression can introduce, for example, 30 msec of delay into the signal. Second, there may be a delay introduced by the source converting the data from non-packet form into packet form. Generally, the source gateway must receive and store a certain amount of data to fill a packet, and then generate a header to affix to the packet data. This packetization can introduce, for example, 50 msec of delay into the media transfer. Third, there may be a delay due to the inherent asynchronous nature of a packet network. Generally, packets arrive at a destination at varying times, and may even include overlapping and out-of-sequence packets. For the transferring of data files, this xe2x80x9cjitterxe2x80x9d generally does not introduce any significant problems because the data is not time critical. For real-time data, however, such as voice, video or multimedia data, a jitter buffer may be necessary to reconstruct the packets into a real-time message. The jitter buffer can introduce, for example, 100 msec of delay into the media stream because it must compensate for the jitter in the arrival of the packets.
These compression, packetization and jitter delays may all be present in any transfer of data from a source to a destination in a packet network. If a packet VRU receives packetized data from a source and then re-transmits the packetized data to a destination, all three delays may be present in each separate media stream (i.e, from the source to the VRU, and from the VRU to the destination). Adding the second set of delays to the transfer may be unacceptable for real-time media communication. In addition, there may be excess delay associated with the transportation of the two (or more) separate media streams in the network, especially if the originating and terminating parties are located close to each other and the packet VRU is located far from the parties. Generally, this delay may be caused both by the increased distance that the signals must travel, and by all the extra routers and switches and other circuitry which the signals must pass through in the network. Users are very sensitive to delay, which can be distracting at the least, and may cause parties to start talking over one another if the delay becomes too excessive, significantly disrupting the conversation. Delay may even cause sufficient user dissatisfaction to push users to seek another service provider.
Accordingly, it is highly desirable for the packet VRU to reduce or avoid these delays, while at the same time maintaining control of the call. In a preferred embodiment of the invention the packet VRU may utilize protocols available in the packet network to redirect a source""s media stream from the packet VRU to another destination. In this way the media stream is sent directly to the destination instead of passing through the packet VRU. Alternatively, if the packet VRU must perform processing on the message contents, the packets may be directed to the receiving parties, and in addition continue to be sent to the packet VRU. By redirecting the packets directly to the receiving parties, these embodiments generally avoid any additional compression, packetization and jitter delays that would be introduced by a second subsequent media stream from the VRU to the destination.
In a preferred embodiment, the packet VRU generally redirects only the media streams themselves to be sent directly between the parties. The packet VRU may still retain call control over the media streams by maintaining the signaling and user input components of the call. For example, the RTP/RTCP media streams may be redirected to be sent directly between the gateways, but the H.245 and Q.931 call structures between the gateways and the VRU may be kept intact.
In H.323 VoIP architecture, the DTMF or other user signaling may be taken out-of-band from the RTP streams using H.245 UserInputIndication messages, as described in more detail in section 7.12.6 of the H.245 specification. This feature was specified in the H.323v2 specification because some voice compression schemes destroy in-band DTMF information. This feature was intended to allow out-of-band DTMF information to be sent to the same endpoint as the in-band voice information, but this feature may also be exploited to route the user input to a different endpoint than the RTP media stream. H.245 section 7.12.6 User Input also describes a method to provide DTMF duration information in the UserInputIndication messages using Signal and SignalUpdate parameters. This feature may be used to transfer tone duration information out-of-band from the RTP streams. Tone duration is useful in many applications, such as calling card call re-origination.
Thus in a further preferred embodiment of the present invention, a gateway or browser may convert user input indication signals (e.g., DTMF signals from a telephone, or keyboard input from an IP phone) received from a party connected via the gateway or browser into user input indication messages in an out-of-band channel in the H.323 protocol to be read by the packet VRU, separate from the redirected media streams. This may be especially useful for higher compression schemes (e.g., G.723) which cannot properly compress and decompress user input indication signals in-band with the voice signal. By using user input indication messages, the packet VRU advantageously does not need to receive the media streams if the sole reason is to detect user input indication signals, and this approach also circumvents the digital signal processing associated with in-band user input indication detection. Thus the packet VRU may redirect the media streams to travel directly between the parties without passing through the packet VRU, and still maintain call control, including receiving user input indication messages from the users. Alternatively, if the receiving party also needs to receive user input indication signals, for example if the receiving party is a synchronous VRU monitoring user input indication signals, then either the originating gateway or the packet VRU can send the user input indication messages to the destination gateway, which may then convert the messages back into actual user input indication signals added into the voice signal.
In an alternative embodiment, the packet VRU may solely utilize a voice-recognition user interface and therefore not require user input indication signals at all. Alternatively, if the user input indication signals are implemented in-band with the data channel, a user input indication detector in the packet VRU may be implemented, and for further functionality a user input indication generator may also be implemented in the packet VRU. For these latter two embodiments, in addition to the media streams being transferred directly between the parties, the packet VRU would also need to receive copies of the media streams to process the data contained in them. One example of a standard for user input indication data transfer and reproduction is the xe2x80x9cVoice over IP Interoperability Implementation Agreement,xe2x80x9d developed by the International Multimedia Teleconferencing Consortium (xe2x80x9cIMTCxe2x80x9d), located in San Ramon, Calif. and with a WWW site of xe2x80x9chttp://www.imtc.org.xe2x80x9d The specification, which supports two party voice and voice-band calls over IP networks, is based on H.323 standards and includes other telephony-specific requirements and IP specific needs such as directory services and dynamic IP address resolution mechanisms.
In accordance with a preferred embodiment of the present invention, a method for redirecting media in an asynchronous packet network by a system asynchronously connected to the packet network comprises establishing a first call between a first device and the system via the packet network, wherein the first call comprises a first call control structure and a first media stream, and signaling the first device to redirect the first media stream to a second device, wherein the first call control structure is retained between the first device and the system. In a further aspect of this preferred embodiment, the method further comprises establishing a second call between the system and the second device via the packet network, wherein the second call comprises a second call control structure and a second media stream, and signaling the second device to redirect the second media stream to the first device, wherein the second call control structure is retained between the system and the second device.
In accordance with another preferred embodiment of the present invention, a computer program product having a computer readable medium with computer program logic recorded thereon for use in a system asynchronously connected to a packet network for redirecting media in the asynchronous packet network, comprises code for establishing a first call with a first device via the packet network, wherein the first call comprises a first call control structure and a first media stream, code for establishing a second call with a second device via the packet network, wherein the second call comprises a second call control structure and a second media stream, code for signaling the first device to redirect the first media stream to the second device, and code for signaling the second device to redirect the second media stream to the first device, wherein the first and second call control structures are not redirected away from the system.
In accordance with yet another preferred embodiment of the present invention, a system for redirecting media in an asynchronous packet network comprises an asynchronous interface to the packet network, means for establishing a first call with a first device via the packet network, wherein the first call comprises a first call control structure and a first media stream, means for establishing a second call with a second device via the packet network, wherein the second call comprises a second call control structure and a second media stream, means for signaling the first device to redirect the first media stream to the second device, and means for signaling the second device to redirect the second media stream to the first device, wherein the first and second call control structures are not redirected away from the system.
In accordance with still another preferred embodiment of the present invention, a system for redirecting media in an asynchronous packet network comprises an asynchronous interface to the packet network, a call control server, wherein the call control server sets up call control structures to communicate with devices in the packet network via the asynchronous interface for controlling media streams from and to the devices, a voice media server communicating with the call control server, wherein the call control server uses the call control structures to establish media streams between the devices and the voice media server via the asynchronous interface, and an application server communicating with the call control server and the voice media server, wherein the application server instructs the call control server to redirect the media streams to be transmitted directly between the devices without passing through the system, and wherein the call control structures are retained between the devices and the system.
One advantage of a preferred embodiment of the present invention is that a packet VRU may generally provide the existing enhanced services of a synchronous VRU, but in a packet network environment. Another advantage of a preferred embodiment of the present invention is that a packet VRU may provide enhanced services for multimedia communications in addition to voice-only communications. Because of the added multimedia functionality, a packet VRU may also be described as a packet Multimedia Response Unit (xe2x80x9cMRUxe2x80x9d), or a packet Interactive Multimedia Response (xe2x80x9cIMRxe2x80x9d) Unit. All such systems may also be referred to as a packet Enhanced Service Provider (xe2x80x9cESPxe2x80x9d). Of course, with the added multimedia functionality, new enhanced services, such as video conferencing, shared whiteboarding and text chatting, which were not implemented in voice-only communications, will become desirable, and all such enhanced services are intended to be within the scope of the present invention.
A further advantage of a preferred embodiment of the present invention is that repeated conversions from one data format to another data format are avoided because the media is sent directly from source to destination, and not through the packet VRU. In addition, because the packet VRU is implemented as a core device within the packet network instead of as an edge device, the packet VRU does not need to provide multiple device-type access such as for modems and fax machines. Instead, gateways generally direct only the voice calls to the packet VRU and direct fax and modem calls elsewhere. Also, the packet VRU may not need to provide data format conversion between the packet network and another type of network, such as a switched network, although connecting a combined packet/synchronous VRU to both types of networks may still be desirable for some applications.
A further advantage of a preferred embodiment of the present invention is that a packet network interface generally does not require multiple physical ports and an internal switch for connecting more than one party together for enhanced services such as calling card and one-number services. Instead, any switching/routing is handled in the packet network itself. A single packet network interface may handle all traffic with the packet VRU. For example, a single 100 Mbit Ethernet interface may carry over 10,000 5 Kbit G.723 compressed voice channels plus overhead. Alternatively, more than one packet network interface may be implemented. In addition, multiple parties may be connected by redirecting the media streams to travel directly between the parties, without passing through the VRU. Thus the packet VRU may avoid the delays associated with an internal jitter buffer, internal processing of the packets, and separate media streams from the VRU to each party.
A further advantage of a preferred embodiment of the present invention is that a packet VRU may redirect the media streams and still retain control of the call by keeping the call states between the parties and the VRU intact. Redirecting the media streams may free up valuable resources in the packet VRU, such as voice recognition resources, so that they can be used to handle other calls. In addition, the packet VRU may still receive user input indication messages. This embodiment has a further advantage over a synchronous VRU in that it can perform a function similar to RLT in the PSTN, discussed above, but still monitor for user input indication signals and still keep track of the call context. Thus the packet VRU, and not the network, would monitor for user input indication signals. For example, if the packet VRU redirects a calling card caller""s call from a third party to the VRU in response to a user input indication message, the calling card caller would not have to re-enter Card Number and PIN information to make a second calling card call.
Yet another advantage of a preferred embodiment of the present invention is that generally only the amount of bandwidth needed is used in the packet network interface (and throughout the packet network), instead of the 64 Kbps channels generally required for each connection in a switched network.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.